> > In your message of Thu, 20 Oct 1994 21:41:48 BST, you say: > > >the FreeBSD man page for access(2) includes a section titled "CAVEAT" > >which says that "Access() is a potential security hole and should never > >be used." > > hmmm..... access(2) uses the REAL uid, not the EFFECTIVE uid when > testing permissions. The idea is that, when you write a setuid program, > you can check to see if the user has permission to access a file while > you have euid==root. Eg. > > real uid = user > eff uid = root > > The problem I found with using access is that it's actually easier > just to flip real and effective uids, test writability, open the file, etc. > then flip the uids back. If you use normal code, you only have to > worry about the effective uid; however, if you use access(), you have > to worry about both real and eff uid. > > Actually, that's not really a security hole, just additional complexity. > Maybe access() on FreeBSD is a different matter. At least, the access > manpages on sunos and solaris don't mention any holes... The problem its referring to is a race condition; and its due to the way access(2) is normally used, rather than it being a hole in access(2) itself. As you say, access(2) is often used by a privileged process to check whether the current real-uid has access to a given file. If access(2) says the user can access the file, it is then manipulated some time later by *privileged* code. There is no guarantee that the file manipulated by the privileged code is the same file that access(2) verified access to -- the file could have been changed in between, using links or whatever. Seems that to be secure, we'd need a faccess(2) type of call, although I realise that wouldnt be useful or useable in all situations. ------------------------------------------+----------------------------------- Mailed using ELM on FreeBSD | Karl Strickland PGP 2.3a Public Key Available. | Internet: karl@bagpuss.demon.co.uk |